Why was this whole block removed? It seems like it will fundamentally change the behavior of this script.

Really? It does only 1 of the 2 things (when DeleteUnsigned is enabled):

1. Print a message if sbctl is used
2. Clean up after the inability of sbsign to sign in place... with the new code, that is no longer the case

Maybe I should remove the option DeleteUnsigned since it is no longer needed.

What am I missing? I see this block of code as no longer needed.

Are you sure that sbsign won't corrupt its input if you try to overwrite it with output? Is that the case for several prior versions of sbsign?

If it's safe, the better approach would be to replace DeleteUnsigned with something a bit more meaningful like Overwrite and handle that above by just changing what you're passing as the output name to sbsign.

Then I propose UseOriginalFileName:

• true -> *.efi = stays the same.
• false (default) -> *.signed.efi

Or you can think of a better boolean var name?
And I will write the logics to always output to a different file. (solving above discussion)

Do you still want to offer the option, that is available for the sbsigntools method, to keep the original unsigned EFI files?
Since sbctl signs in place, why would we want to keep the unsigned EFI files?

I proposed, and still prefer, Overwrite, which is both shorter and more descriptive.

Why sort?

Glad you asked. The sbverify command modifies the efi files last modified timestamp resulting in refind showing as the default ZBM the last of the this array (last of the array is first in rEFInd list). This sort solution allows the user to controll the rEFInd order via naming.

Do you see an issue with using sort?

Yes, this is not the place to hack around rEFInd sorting specifics. There is no need to sort unless this script depends on the order of the array, which it does not.

As above, why sort?

You aren't actually running this command, so the test on the output you are expecting will always fail.

Furthermore, if possible, it would be better to distinguish whether the input is already signed by the exit code, rather than grepping output for a magic string.

Off-topic: I'm glad I'm invested time into this PR.

On-topic: This exact line of code behaves as expected. I can see it only signs the files that need signing. How do you explain it?
Should I replace the double qoutes with qx or backticks? What do you prefer?

I will look into the exit codes and see if that is an option.

The issue is not with the sbsign call.

my $verify_output = "sbverify --cert $KeyDir/$CrtFileName $ZBM/$_ 2>&1";

just sets a string, it doesn't actually run sbverify.

Replacing the unsigned input with the signed output is destructive and probably shouldn't be the default behavior. It seems better to leave this as it was, creating a separate signed file.

This is exactly the default behavior of sbctl. The Arch wiki shows an example using the same approach:

sbsign --key db.key --cert db.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux

Have you had bad experiences with sbsign leaving you with a corrupt file?

Never assume that a process will complete successfully, especially when you are changing existing behavior that is less destructive. As I noted earlier, replacing the DeleteUnsigned option with an Overwrite and using that to control whether --output is passed at all is a better approach than always clobbering inputs.

Are you sure that sbsign won't corrupt its input if you try to overwrite it with output? Is that the case for several prior versions of sbsign?

If it's safe, the better approach would be to replace DeleteUnsigned with something a bit more meaningful like Overwrite and handle that above by just changing what you're passing as the output name to sbsign.

The Name part seems superfluous, and CertFile would be a bit more readable than CrtFile.